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Abstract 


Giotto  is  a  programming  model  for  embedded  control  systems  that  is  applicable  to  hard  real¬ 
time  specifications  that  are  periodic  and  feature  multi-modal  behavior.  Examples  of  such  systems 
include  fly-by-wire  or  brake-by-wire  systems  where  sensor  readings  must  be  periodic  and  there  are 
multiple  modes  of  operation. 

Ptolemy  II  is  a  university  based  open  source  modeling  and  simulation  framework  that  supports 
model-based  design,  and  facilitates  actor  oriented  and  objected  oriented  programming.  It  serves 
as  a  laboratory  for  the  modeling  and  simulation  necessary  in  the  design  of  a  real-time  embedded 
system.  Ptolemy  also  has  a  C  code  generation  framework  that  generates  code  for  different  targets. 

Ptolemy  II  has  an  implementation  of  the  Giotto  programming  model,  that  allows  the  simu¬ 
lation  of  Giotto  models  in  Ptolemy  II.  In  this  report  we  discuss  our  ability  to  implement  Giotto 
semantics  using  code  generation  and  a  real-time  operating  system.  We  illustrate  these  techniques 
with  Ptolemy  II  and  the  FreeRTOS  embedded  operating  system.  To  illustrate  these  techniques  we 
extend  the  code  generation  framework  within  Ptolemy  II  to  generate  C  code  for  the  Giotto  pro¬ 
gramming  model.  We  have  implemented  a  C  code  generation  adapter  in  Ptolemy  II  for  the  Giotto 
model  of  computation  targeted  to  systems  capable  of  running  the  FreeRTOS  operating  system.  We 
present  an  elevator  controller  as  an  example  that  uses  the  code  generation  framework. 
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1  Introduction 


In  real-time  embedded  systems  it  is  important  to  guarantee  timing  eonstraints  and  correct  func¬ 
tionality.  This  is  evident  because  in  many  applications  such  as  braking  to  avoid  an  oncoming  car, 
stimulating  a  person’s  heart  in  an  emergency,  or  a  plethora  of  other  control  applications,  func¬ 
tional  correctness  and  timing  accuracy  is  extremely  important.  The  use  of  hard  real-time  systems 
has  expanded  significantly;  however,  there  are  very  few  high-level  languages  that  support  precise 
timing  specifications  at  the  software  level  that  can  be  mapped  directly  to  hardware.  Most  popular 
high-level  programming  languages  such  as  C,  C-i-i-  and  Java  do  not  provide  a  way  for  the  user  to 
specify  precise  timing.  As  a  result,  the  user  generally  manually  counts  cycles  on  their  platform. 
This  practice  breaks  the  portability  of  their  code  to  other  platforms.  Clearly  timing  is  of  great 
importance  in  the  embedded  domain  and  numerous  efforts  have  gone  into  providing  either  annota¬ 
tions  to  existing  programming  languages,  new  models  of  computation  with  timing  semantics  built 
in,  and  even  hardware  with  support  for  precise  timing  semantics. 

Examples  of  models  of  computation  that  support  precise  timing  specifications  at  a  high  level 
include  Esterel  [1^,  Sync  Charts  @,  Eustre  ifTTl.  Signal  [|5l,  PTIDES  ifTOll  and  Giotto  [fT4l.  Esterel, 
Eustre,  Signal  and  Sync  Charts  are  synchronous  reactive  programming  languages,  which  are  used 
to  program  reactive  systems.  Reactive  systems  continuously  interact  with  their  environment,  and 
real-time  reactive  systems  are  also  subject  to  externally  defined  timing  constraints  [O.  In  syn¬ 
chronous  systems  outputs  are  produced  in  the  same  clock  tick  that  the  input  is  received.  This  is 
similar  to  a  synchronous  hardware  circuit  that  produces  its  output  after  receiving  an  input,  and  be¬ 
fore  receiving  its  next  input  value.  PTIDES  builds  on  discrete  event  semantics  and  guarantees  on 
time  reading  of  sensor  values  and  delivery  of  outputs  at  actuators.  Giotto  is  aimed  at  time  periodic 
real-time  systems  with  different  modes  of  operation  and  precisely  defined  mode  transitions. 

The  complexities  of  including  timing  specifications  in  a  programming  language  and  the  need 
to  create  software  concurrently  with  the  physical  system  with  which  it  interacts  are  important 
factors  that  lead  to  the  engineering  approach  initially  known  as  model  integrated  computing  [|^ 
and  later  known  as  model-based  design.  A  model  is  a  representation  of  a  designer’s  understanding 
of  a  system  that  includes  the  computer-based  system  and  the  physical  architecture  and  operating 
environment  [|2n.  In  model-based  design,  models  specify  the  tasks  to  be  completed,  and  the 
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execution  of  tasks  is  governed  by  a  model  of  computation.  The  designer  or  engineer  can  choose 
the  model  of  computation  to  govern  how  their  model  should  execute  [[T6ll  and  create  a  model  that 
is  representative  of  their  system. 

In  model-based  design  it  is  important  to  define  a  model  of  computation,  and  very  helpful  to 
have  a  simulator  for  this  model  of  computation.  Use  of  simulation  environments  has  also  revealed 
the  importance  of  having  code  generation  as  an  integral  part  of  the  framework.  Some  modeling 
and  simulation  environments  include  The  MathWorks  Simulink  [j3,  National  Instruments  Lab- 
VIEW  [fT9ll  and  the  Ptolemy  II  environment.  Simulink  and  Lab  VIEW  are  commercial  tools,  and 
Ptolemy  II  is  a  university  based  open  source  project.  Ptolemy  II  enables  heterogeneous  model¬ 
ing,  and  Simulink,  Lab  VIEW,  and  Ptolemy  enable  model-based  design  and  simulation,  and  feature 
code  generation  for  different  targets.  The  MathWorks  describes  Simulink  on  their  website  [|2l  as 
“an  environment  for  multi-domain  simulation  and  model-based  design  for  dynamic  and  embed¬ 
ded  systems.  It  also  features  real-time  workshop  that  allows  you  to  generate  and  run  C  code  for 
algorithms  modeled  in  simulation.” 

It  is  important  to  note  that  this  project  builds  on,  yet  takes  a  slightly  different  approach  from  [fT^ 
which  also  explores  code  generation  from  Ptolemy  II  for  Giotto.  This  prior  work  generates  Giotto 
code,  which  uses  an  ES  machine  scheduler  for  the  KURT  Linux  RTOS.  It  produces  function  pro¬ 
totypes  and  leaves  it  to  the  designer  to  write  the  C  code  for  Giotto  tasks  to  match  the  function 
prototypes.  The  prior  work  requires  the  user  specify  the  types  of  all  ports;  however,  here  the  types 
of  ports  are  inferred  from  the  actors.  ffT^  produces  Giotto  code  and  then  requires  the  user  feed  the 
Giotto  file  to  a  Giotto  compiler  to  compile  it  to  E  code;  as  well  as  the  function  table  to  map  E  code 
function  calls  to  driver  functions  as  well  as  produce  the  S  code.  Instead  of  requiring  the  designer 
write  C  code  for  all  actors,  our  project  generates  C  code  for  actors  and  allows  the  designer  to  also 
insert  C  code  in  EmbeddedCActors  if  it  is  necessary  to  implement  an  actor  that  is  not  currently 
supported.  We  generate  C  code  directly  from  the  Ptolemy  II  Giotto  model  for  a  platform  capable 
of  running  the  EreeRTOS  embedded  operating  system. 

In  this  work  we  step  away  from  the  E  and  S  machine  specification.  This  approach  to  code 
generation  from  a  Giotto  model  is  different  from  [fTSll  but  valuable  because: 


•  Giotto  only  provides  semantics  about  when  tasks  should  be  completed; 
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•  E  code  is  used  for  portability  to  multiple  targets  and  S  code  because  most  platforms  provide 
no  direct  control  over  when  tasks  exeeute; 

•  We  attain  portability  by  using  the  Ptolemy  II  model  as  our  speeifioation; 

•  E  eode  and  S  code  still  require  interpreters  for  your  particular  target; 

•  C  code  or  code  for  a  programming  language  still  needs  to  be  generated  for  the  functionality 
of  tasks  as  well  as  for  drivers  and  the  exeeution  of  the  generated  eode. 


Instead  of  using  E  eode  and  S  code,  we  use  the  model  speeified  in  Ptolemy  II  as  our  portability 
meehanism  to  multiple  targets,  and  generate  C  code  directly  from  the  model  specification  since 
our  target  RTOS  provides  direet  eontrol  over  timing.  The  objeetives  of  this  projeet  are  to  generate 
C  eode  that  adheres  to  Giotto  semanties,  but  also  to: 


•  Continue  extending  the  C  eode  generation  framework  in  Ptolemy  II  for  multiple  targets; 

•  Build  on  existing  work  which  allows  the  reuse  of  actors  whenever  possible; 

•  Allow  the  eustomization  of  aetors  to  the  target  when  neeessary; 

•  Allow  the  user  to  easily  create  actors  or  to  embed  C  code  in  an  EmbeddedCAetor  and  still 
utilize  the  code  generation  facilities  in  Ptolemy  II. 


With  the  use  of  a  scheduler,  we  generate  C  code  directly  from  the  model  and  forgo  the  speci¬ 
fication  of  the  Embedded  Machine  code  sinee  that  information  is  also  provided  by  the  Ptolemy  II 
Giotto  model.  In  our  design  we  incorporate  aspects  normally  handled  by  the  E  and  S  maehine  by 
using  the  API  tools  offered  by  EreeRTOS. 


In  this  report  we  diseuss  our  ability  to  implement  Giotto  semanties  using  eode  generation  and 
a  real-time  operating  system.  We  illustrate  these  teehniques  with  Ptolemy  II  and  the  EreeRTOS 
embedded  operating  system.  To  illustrate  these  techniques  we  extend  the  eode  generation  frame¬ 
work  within  Ptolemy  II  to  generate  C  code  for  the  Giotto  programming  model.  Giotto,  Ptolemy  II, 
and  EreeRTOS  are  discussed  in  greater  detail  in  Section]^  Section [^diseusses  the  extension  of  the 


Ptolemy  II  eode  generation  framework  and  the  design  of  the  seheduler.  Section  3.6  discusses  the 
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limitations  of  the  work,  Section  [^presents  a  controller  application,  and  Section  [^discusses  future 
work. 


2  Background 


In  this  section  we  provide  an  overview  of  the  Giotto  model  of  computation,  introduce  the  Ptolemy 
II  framework,  present  the  Giotto  implementation  in  Ptolemy  II,  and  briefly  give  an  overview  of 
FreeRTOS,  the  embedded  OS  target  for  the  Giotto  C  code  generator. 


2.1  Giotto 

Giotto  is  a  programming  model  for  embedded  control  systems  [|T4ll.  and  is  most  useful  for  hard 
real-time  specifications  that  are  periodic  and  feature  multi-modal  behavior.  Giotto  is  useful  for 
control  systems  such  as  fly-by-wire  or  brake-by-wire  where  the  responses  of  the  system  must  be 
periodic  and  there  are  multiple  modes  of  operation.  Examples  of  common  modes  of  operation  in 
the  automobiles  include  startup,  cruise  control,  normal  operation,  and  a  degraded  operation  mode 
in  case  of  partial  equipment  failure.  Giotto  serves  as  a  contract  between  a  control  engineer  and 
a  software  engineer  to  produce  the  behavior  specified  by  the  Giotto  model.  In  addition,  Giotto 
allows  the  control  engineer  and  software  engineer  to  communicate  effectively  without  the  need  to 
get  into  implementation  details.  Control  systems  are  generally  specified  using  commercial  tools 
such  as  Simulink  [|2l,  or  control  engineers  may  manipulate  differential  equations  and  modal  logic 
with  mathematical  tools. 

Giotto  allows  some  flexibility  in  implementation  as  long  the  implementation  conforms  to  the 
timing  specification.  In  fact  Giotto  does  not  specify  how  a  program  should  be  implemented  on  a 
particular  platform.  Instead,  it  allows  the  user  to  specify  the  semantics  of  time-triggered  sensor 
readings,  task  invocations,  actuator  updates,  and  mode  switches  independent  of  the  platform  used 
to  implement  it  [[l4l[T5l|.  As  a  result,  Giotto  tasks  can  be  scheduled  on  platforms  with  a  single  CPU, 
which  use  preemptive  priority  driven  multitasking,  or  time-slicing,  or  on  a  platform  with  multiple 
CPUs. 
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Figure  1:  Task  Invocation.  Reused  with  permission  [fT4ll. 


One  should  note  that  a  giotto  program  is  schedulable,  or  will  execute  correctly,  if  there  exists 
a  scheduling  policy  that  will  meet  the  requested  deadlines  on  a  particular  processor  given  its  re¬ 
sources  and  time  constraints  ifTSl .  Before  producing  a  schedule,  the  Giotto  compiler  or  scheduler 
must  ensure  that  the  cumulative  worst-case  execution  times  of  tasks  in  a  mode,  or  the  total  time  to 
execute,  is  less  than  or  equal  to  the  logical  execution  time  of  a  mode.  The  logical  execution  time 
of  a  mode  is  the  rate  of  execution  specified  by  the  mode’s  periodic  behavior.  The  Giotto  compiler 
just  needs  to  ensure  that  sensors  and  actuators  are  written  at  the  times  requested  in  the  Giotto  se¬ 
mantics.  It  is  possible  to  add  tasks  to  a  mode  without  changing  the  code  behavior  as  long  as  the 
processor  can  accommodate  the  additional  load  iflBll. 

Giotto  code  is  generally  executed  on  virtual  execution  engines  IfTSlI  referred  to  as  an  Embedded 
(E)  machine  and  a  Scheduling  (S)  machine.  The  virtual  execution  engines  are  necessary  because 
most  widely  available  platforms  do  not  have  direct  support  for  precise  timing  semantics.  A  Giotto 
compiler  produces  E  code  for  the  E  machine  and  S  code  for  the  S  machine.  E  code  provides 
the  “deadlines  or  release  times  of  tasks”  ifTSl  and  reacts  to  the  platform’s  passage  of  time.  At  a 
deadline,  the  E  code  generally  calls  a  function  referred  to  as  a  driver  that  reads  values  at  sensors 
or  writes  values  to  the  outside  world  at  actuators.  S  code  specifies  a  “feasible  schedule”  of  the 
deadlines  specified  by  E  code.  Depending  on  the  scheduling  mechanism  of  a  platform,  S  code  may 
run  a  task  for  a  small  amount  of  time  and  resume  the  task  at  a  later  time,  or  it  may  run  a  task  until 
completion.  Some  implementations  of  a  Giotto  environment  combine  the  E  and  S  machine;  when 
combined  they  are  referred  to  as  schedule  carrying  code  ifTSl . 


To  obtain  a  better  understanding  of  Giotto  it  is  essential  that  we  explore  the  basics  of  the  Giotto 
programming  model.  In  Giotto,  a  task,  graphically  represented  in  Eigure[^  is  the  basic  functional 
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Figure  2:  Graphical  Representation  of  task  communication  in  a  mode.  Reused  with  permis¬ 
sion  [IT4l. 

unit.  If  multiple  tasks  need  to  be  run  concurrently,  they  are  put  in  a  mode,  as  are  tl  and  t2  shown 
in  Figure]^  Each  task  has  a  set  of  ports  P,  with  input  ports  (In  C  P),  output  ports(Out  C  P),  and 
maintains  its  state  through  private  ports  (Priv  C  P).  Tasks  in  a  mode,  i.e.  U,  tj,  have  distinct  input 
ports,  In(ti)  nln(tj)  =  0  for  each  two  tasks  ti  and  tj  of  a  mode.  All  input  ports  are  distinct  from  all 
other  input  ports;  however,  tasks  may  share  output  ports  as  long  as  they  are  not  invoked  in  the  same 
mode.  Task  inputs  are  read  only  at  the  beginning  of  a  period  and  task  outputs  are  written  only  at 
the  end  of  the  period.  The  output  can  be  computed  at  any  time  but  should  only  be  provided  to  other 
tasks  or  to  the  outside  world  at  specified  times  ifTdl .  The  task’s  function  /  specifies  what  should  be 
done  with  the  inputs  to  produce  the  outputs.  If  several  tasks  are  to  be  executed  concurrently,  they 
are  included  in  a  mode,  and  a  system  can  change  from  one  mode  of  operation  to  another  at  multiple 
points  during  the  model’s  execution.  Each  mode  has  a  period(7r)  that  specifies  how  often  the  action 
of  the  mode  should  be  repeated,  and  each  task  has  a  frequency(a;t)  that  specifies  how  many  times 
the  task  should  be  executed  within  a  mode  period.  In  the  mode  shown  in  Eigurej^  task  1  executes 
once  every  10ms,  and  task  2  executes  once  every  Sms.  Each  mode  also  has  guards  that  specify 
a  mode  switch  frequency.  The  mode  switch  frequency  specifies  how  many  times  within  a  period 
the  possibility  of  a  mode  switch  should  be  checked  and  taken  if  possible.  Since  it  is  possible  to 
interrupt  a  task’s  execution  when  switching  from  one  mode  to  another,  one  must  ensure  that  a  task 
that  can  be  interrupted  in  one  mode  is  present  in  the  next  mode  so  it  can  continue  its  execution. 

Communication  between  tasks  is  done  via  ports  in  Giotto.  Ports  are  specific  locations  in  mem- 
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ory  or  variables  dedicated  to  storing  information.  Drivers  specify  which  output  values  should  be 
copied  to  specific  ports  and  which  port  values  should  be  copied  from  a  port  to  an  input.  Ports  hold 
their  value  over  time  until  they  are  updated  by  a  driver.  Sensor  ports  are  updated  by  the  environ¬ 
ment,  and  actuator  ports  and  task  ports  are  updated  by  the  program  ffT4l .  Task  ports  communicate 
data  between  concurrent  tasks  and  can  also  be  used  to  communicate  between  modes  in  the  event 
of  a  mode  switch.  Mode  ports  are  given  a  value  every  time  the  mode  is  entered  [[T4ll.  In  Figure]^ 
oi  —  05  are  mode  ports.  oi  is  read  when  the  mode  begins  and  02  —  05  are  updated  every  10ms  and 
can  be  used  to  pass  information  from  one  mode  to  another  in  the  event  of  a  mode  switch.  In  Fig¬ 
ure]^  fi  specifies  the  actions  that  should  be  taken  on  the  inputs  to  produce  outputs,  Wact  specifies 
actuation  frequency,  and  d,  specifies  drivers  which  move  information  from  ports  to  inputs,  or  from 
outputs  to  an  actuator. 


2.1.1  Related  Work 

Giotto  appears  to  have  been  influenced  by  Harel’s  state  charts  ifT^.  which  extend  state  transition 
diagrams  and  add  notions  of  hierarchy,  concurrency  and  communication.  Giotto  was  also  influ¬ 
enced  by  the  Time-Triggered  Architecture(TTA),  since  TTA  meets  hard  real-time  requirements  in 
distributed  systems  and  is  based  on  the  time-triggered  programming  model.  TTA  was  intended  for 
similar  applications  as  Giotto  such  as  brake-by-wire  or  the  control  of  an  airplane.  While  Giotto 
splits  things  into  tasks,  TTA  splits  things  up  into  clusters  and  nodes.  TTA  provides  a  “fault-tolerant 
global  time  base  with  known  precision”  IITtI  at  each  node.  In  TTA,  all  events  that  occur  within  a 
certain  interval  of  time  are  interpreted  as  occurring  simultaneously  and  events  that  occur  outside 
the  interval  can  be  ordered  uni.  Giotto  differs  from  TTA  since  it  comes  with  a  hardware  and 
protocol  independent  programming  model  for  time-triggered  applications  [[T4ll. 

FlexRay,  a  bus  architecture,  has  also  been  influenced  by  TTA.  FlexRay  is  the  latest  system 
being  used  for  communication  between  various  control  devices  in  automobiles.  FlexRay  is  time- 
triggered  and  employs  time  division  multiple  access  (TDMA)  for  arbitration  between  multiple 
nodes  on  a  bus.  This  communication  was  traditionally  being  done  with  a  Control  Area  Network 
(CAN);  however,  as  more  of  the  automotive  industry  adopts  brake -by- wire/X-by- wire,  as  is  done 
in  many  airplanes,  error  and  fault  detection  needs  surpass  the  feasibility  of  CAN,  and  provides 
support  for  the  FlexRay  protocol. 
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The  Timing  Definition  Language  (TDL)  is  a  derivative  of  Giotto.  TDL  is  a  programming  model 
for  concurrent  hard  real-time  software.  Like  Giotto,  in  TDL  sensor  and  actuator  ports  are  used  to 
interact  with  the  environment,  a  program  is  in  one  of  many  possible  modes,  every  mode  consists  of 
periodic  activities,  a  mode  has  a  fixed  period,  and  timing  and  interaction  of  activities  follow  logical 
execution  time  semantics  [|24l.  Unlike  Giotto,  TDL  provides  a  top-level  structure  called  a  module. 
A  module  consists  of  actuators,  sensors  and  modes.  According  to  Derler  et.  al.  modules  are  useful 
for  distributed  applications,  where  it  is  possible  to  break  the  specification  into  smaller  components 
to  be  executed  in  parallel  on  different  processors  [l20l .  Giotto  limits  the  number  of  mode  switch 
conditions  that  may  evaluate  to  true  to  one  to  provide  determinism;  however,  in  TDL  “mode  switch 
guards  are  evaluated  in  the  textual  order  from  top  to  bottom  and  a  mode  switch  is  performed  for 
the  condition  that  evaluates  to  true  [l20ll.”  Directors  for  Giotto  and  TDL  are  implemented  in  the 
Ptolemy  II  simulation  framework.  An  in-depth  discussion  of  the  TDL  director  in  Ptolemy  II  is 
in 


and  the  Giotto  implementation  in  Ptolemy  II  is  presented  in  Section  2.3 


2.2  Ptolemy  II 

Ptolemy  II  [123]|  is  an  open  source  modeling  and  simulation  framework  being  developed  at  the 
University  of  Califomia-Berkeley  that  supports  model-based  design.  Ptolemy  II  facilitates  actor 
oriented  and  object  oriented  modeling.  Actor  oriented  modeling  is  an  alternative  to  the  estab¬ 
lished  object  oriented  methodology,  where  actors  allow  actions  to  take  place  on  the  evolving  data 
which  flows  through  them  [[8l.  Ptolemy  II  facilitates  the  modeling  and  simulation  of  the  design 
of  a  real-time  embedded  system.  The  design  can  be  concurrent,  and  a  design’s  behavior  is  gov¬ 
erned  by  models  of  computation  implemented  in  the  Ptolemy  II  framework.  A  small  subset  of  the 
models  of  computation  relevant  to  this  project  include:  DE:  discrete-event  modeling;  FSM:  finite 
state  machines  and  modal  models;  SDF:  synchronous  data  flow;  TDF:  timed  description  language; 
and  Giotto:  periodic  time-driven.  Ptolemy  II  also  has  heterogeneous  capabilities  which  allow  the 
designer  to  combine  different  models  of  computation. 

In  Ptolemy  II,  when  an  actor  fires,  its  behavior  for  a  particular  model  of  computation  is  gov¬ 
erned  by  a  director  which  is  specified  for  the  particular  model  of  computation.  A  designer  can 
select  the  director  that  specifies  the  desired  behavior  of  a  model,  and  then  create  and  simulate  their 
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model.  In  Ptolemy  II  aetors  are  governed  by  an  abstraet  semanties,  which  are  rules  that  dictate  how 
an  actor  should  behave.  A  simplification  of  the  abstract  semantics  as  it  applies  to  Giotto  includes 
pre-initialization,  initialization,  firing,  and  wrap-up.  During  pre-initialization  in  simulation,  the 
Giotto  director  determines  whether  the  frequencies  specified  by  the  actors  are  permissible.  During 
initialization  the  ports  and  actors  are  assigned  their  specified  default  values.  After  initialization, 
actors  are  executed  in  the  firing  stage. 

In  addition  to  being  a  modeling  and  simulation  framework,  Ptolemy  II  also  features  an  extend¬ 
able  C  code  generation  framework  for  multiple  models  of  computation.  Code  generation  capabili¬ 
ties  for  multiple  targets  are  provided  with  many  modeling  frameworks  such  as  Simulink  Real-Time 
workshop,  and  Lab  VIEW  microprocessor  SDK. 

The  Ptolemy  II  C  code  generation  framework  takes  a  model  specified  with  actors  and  directors 
and  generates  code  for  a  particular  target  that  maintains  the  semantics  of  the  original  model.  The 
C  code  generation  framework  is  based  on  an  adapter-based  architecture,  where  adapters  generate 
code  for  specific  targets.  Each  actor  has  a  language-specific  (C,VHDE,etc.)  adapter  file,  while 
each  target  has  its  own  target-specific  adapter  file  flUl. 


2.3  Giotto  in  Ptolemy  II 

The  Giotto  model  of  computation  is  implemented  as  a  domain  in  the  Ptolemy  II  simulation  and 
modeling  environment.  A  Giotto  model  is  created  with  a  Giotto  Director  in  Ptolemy  II.  The  period 
TT  of  the  mode  is  specified  as  the  period  parameter  to  the  director  and  the  frequency  of  each  task  ujt 
is  specified  as  a  frequency  parameter  to  each  Ptolemy  II  actor.  If  no  values  for  the  period  and  actor 
frequencies  are  provided  as  parameters,  default  values  of  0.1  and  1  are  assumed  respectively  [[7l. 

In  [[T4l  a  mode  in  Giotto  consists  of  all  tasks  to  be  run  concurrently  with  a  particular  period.  In 
Ptolemy  II,  a  mode  is  slightly  different  but  allows  all  models  expressible  in  llT4ll .  Ptolemy  II  allows 
the  use  of  hierarchy  that  proves  to  be  very  convenient  in  the  specification  of  control  behavior.  In 
addition  it  also  reduces  the  number  of  distinct  mode  combination  specifications  that  are  necessary 
in  [1T4| .  A  Ptolemy  II  mode  is  specified  inside  a  finite  state  machine  modal  model  and  improves 
the  flattened  specification  present  in  [[T4l  with  the  use  of  hierarchy.  In  Ptolemy  II  tasks,  which 
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are  referred  to  as  actors,  at  the  same  level  of  hierarchy  execute  concurrently  and  a  modal  model 
contains  tasks  that  should  be  switched  when  a  guard  is  enabled.  If  it  is  desirable  to  have  three 
tasks:  A,  B,  and  C,  where  task  A  is  always  running  and  task  C  should  replace  task  B  when  a 
certain  condition  is  met,  a  designer  could  specify  that  in  Ptolemy  II  as  is  shown  in  Figure  The 
lower  portion  of  Figure]^ shows  how  the  model  is  specified  with  Ptolemy  II  and  the  upper  portion 
of  the  figure  shows  the  logical  execution  times  of  each  task  based  on  their  frequencies,  and  on  the 
period  parameter  tt  of  the  Giotto  Director. 

Ptolemy  II  allows  hierarchy  through  the  use  of  composite  actors.  A  composite  actor  contains 
actors  and  in  some  cases  a  director.  If  no  director  is  present  inside  the  composite  actor  the  actor  is 
transparent.  If  however  there  is  a  director  present  inside  a  composite  actor  the  frequencies  of  the 
tasks  inside  the  composite  actor  are  all  interpreted  to  be  relative  to  the  frequency  of  the  composite 
actor  itself.  If  a  composite  actor  with  frequency  2  contains  a  Giotto  Director,  and  a  task  with 
frequency  3,  the  interpreted  frequency  of  the  task  inside  a  composite  actor  is  6. 

Each  Giotto  model  is  expected  to  specify  a  period  as  an  attribute  to  the  Giotto  Director,  the 
frequency  of  each  task  as  an  attribute  to  each  actor,  as  well  as  initial  values  for  outputs.  If  Giotto 
directors  are  used  inside  a  composite  actor,  the  period  of  the  top  most  Giotto  director  is  used,  but 
the  frequencies  of  the  tasks  inside  the  composite  actor  are  relative  to  the  frequency  of  the  composite 
actor. 

For  the  purposes  of  simulation  it  is  also  possible  to  set  the  number  of  times  you  wish  to  have  the 
model  run.  This  can  be  specified  as  a  parameter  called  iterations  to  the  Giotto  director.  It  should 
be  noted  that  since  Ptolemy  II  allows  hierarchical  models,  if  another  Giotto  director  is  specified 
within  a  composite  actor,  only  the  topmost  Giotto  director’s  period  parameter  is  used  along  with 
the  frequency  parameters  of  each  director  and  actor.  One  can  run  the  model  in  the  Ptolemy  II 
framework,  insert  a  code  generation  actor  to  generate  E  Machine  code  fITSll.  or  insert  a  C  Code 
Generation  actor  to  generate  C  code  directly. 
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Giotto  C  Code  Generator  Example 

1 .  Click  on  the  "Double  click  to  generate  code" 
box. 

2.  A  window  with  the  Giotto  code  will  come  up. 

3.  Save  the  file  as  main.c 

4.  Copy  over  to  the  FreeRTOS  directory 
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Double  click  to 
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frequency  2 


Figure  3:  Simple  Giotto  Model  in  Ptolemy  II  with  three  aetors 
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Figure  4:  Hierarehy 
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2.4  FreeRTOS 


FreeRTOS  was  created  by  Riehard  Barry  and  the  FreeRTOS  team,  and  it  is  eontinually  being  de¬ 
veloped  and  released.  FreeRTOS  is  a  “portable,  open  souree,  mini  real-time  kernel  that  ean  be  used 
in  eommereial  applieations  Il22l.”  It  has  versions  available  for  a  number  of  widely  used  mieroeon- 
troller  arehiteetures,  whieh  makes  the  possibility  of  extending  use  and  adoption  of  the  Ptolemy 
eode  generation  infrastrueture  more  promising.  In  addition,  it  “offers  a  smaller  and  easier  real¬ 
time  proeessing  alternative  for  applieations  where  eCOS,  embedded  Linux  (or  Real-Time  Linux), 
and  uCLinux  eannot  fit,  are  not  appropriate,  or  are  not  available  (23.” 

FreeRTOS  uses  a  prioritized  preemptive  seheduling  poliey  that  ensures  that  the  highest  pri¬ 
ority  task  in  the  running  state  is  the  task  given  proeessing  time.  It  has  support  for  eooperative 
seheduling  and  shares  proeessor  time  equally  between  tasks  of  equal  priority  if  they  are  able  to  run 
simultaneously.  As  a  result,  FreeRTOS  is  a  good  target  for  a  eode  generation  framework.  Some  of 
FreeRTOS’s  features  inelude:  preemptive,  eooperative,  and  hybrid  eonfiguration  options;  support 
for  tasks  and  eoroutines;  an  exeeution  traee  funetionality;  staek  overflow  deteetion;  queues;  binary, 
eounting,  and  reeursive  semaphores;  and  mutexes  whieh  feature  priority  inheritanee  (23.  In  addi¬ 
tion  to  the  general  thread  ereation  API  expeeted  in  an  RTOS,  FreeRTOS  also  has  API  support  to 
set  a  periodie  rate  for  the  exeeution  of  a  task  with  the  vTaskDelayUntil  method.  In  addition  the 
API  provides  methods  to  suspend  and  later  resume  the  exeeution  of  tasks.  These  features  make 
FreeRTOS  a  very  good  mateh  for  the  periodie  nature  of  the  Giotto. 


3  Design 

3.1  Framework  Description 

This  work  ereates  a  Giotto  adapter  for  the  Ptolemy  II  C  eode  generation  framework  (3-  A  pieture 
of  the  framework  applieable  to  this  work  is  shown  in  Figure  Please  note  that  dashed  segments 
of  the  framework  have  not  eurrently  been  implemented  for  FreeRTOS.  A  user  speeifies  the  design 
in  Ptolemy  IT  By  inserting  and  double-elieking  on  a  CCodeGeneration  aetor,  the  user  starts  the  C 
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Figure  5:  Design  Framework 

code  generation  framework,  which  can  generate  C  code  for  different  targets. 

The  generated  code  creates  ports,  actor  variables,  driver  methods,  task/actor  code,  as  well  as 
scheduling  and  coordination  code.  Scheduling  thread(s)  as  well  as  threads  for  each  frequency  in 
the  model  are  created.  Scheduling  threads  mange  a  global  notion  of  timing  and  let  tasks  know 
when  they  can  begin  executing.  Task  code  implements  the  behavior  of  Ptolemy  II  actors,  and  the 
scheduling  thread  coordinates  the  execution  of  drivers  and  actor  code. 


3.2  Giotto  C  Code  Generation 

To  generate  C  code  for  Giotto  to  run  on  the  FreeRTOS  platform,  we  created  a  Giotto  Domain  under 
the  C  code  generation  folder,  and  also  created  a  target- specific  adapter  for  the  Giotto  Director  as 
well  as  a  board-specific  adapter  implementation  for  the  Timed  Plotter  actor.  The  C  code  generation 
framework  follows  the  pre-initialize,  initialize,prefire,  fire,  and  post  fire  semantics  of  Ptolemy  II 
and  produces  one  C  file  that  the  user  can  compile  and  run  on  their  target. 

Each  Giotto  model  is  expected  to  specify  a  period  as  an  attribute  to  the  Giotto  Director,  the 
frequency  of  each  task  as  an  attribute  to  each  actor,  as  well  as  initial  values  for  outputs.  If  a  period 
is  not  specified  it  defaults  to  0.1  seconds,  an  unspecified  frequency  defaults  to  1,  and  an  unspecified 
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initial  output  value  defaults  to  zero  for  integral  types  and  null  for  other  types.  If  Giotto  directors  are 
used  inside  a  composite  actor,  the  period  of  the  top-most  Giotto  director  is  used,  but  the  frequencies 
of  the  tasks  inside  the  composite  actor  are  relative  to  the  frequency  of  the  composite  actor. 

In  the  code  generated,  we  attempt  to  use  the  facilities  of  the  RTOS  such  as  the  fixed  pri¬ 
ority  execution  of  threads  ,where  the  processor  is  given  to  the  thread  with  highest  priority  and 
shares  the  processor  between  equal  priority  threads  that  are  ready  to  run.  We  also  utilize  the 
vTaskDelayUntil  method  in  the  FreeRTOS  API.  The  vTaskDelayUntil  method  allows  a  task 
to  wait  a  specified  number  of  kernel  ticks  from  the  last  time  it  was  called  by  the  same  task.  The 
vT askDelayU ntil  method  takes  two  parameters.  We  will  call  parameter  1 ,  which  is  passed  by  ref¬ 
erence,  xLastWakeTime  and  parameter  2  x Frequency.  xLastWakeTime  is  the  value  with  the 
last  time  the  vT  askDelayU  ntil  method  was  called.  Prior  to  the  first  call  to  the  vT  askDelay  Method 
method  the  xLastWakeTime  parameter  is  initialized  to  the  current  kernel  tick  count.  The  sec¬ 
ond  parameter  tells  the  number  of  kernel  ticks  since  the  last  delay  to  yield  the  processor.  In  the 
vTaskDelayUntil  method,  if  the  kernel  tick  count  has  passed  xLastWakeTime  + x Frequency, 
the  method  returns  immediately  without  waiting.  Otherwise  it  blocks  for  the  necessary  number 
of  kernel  ticks  to  resume  execution  at  xLastWakeTime  +  x Frequency.  As  a  result,  A  constant 
value  for  xFrequency  produces  periodic  execution  of  a  thread. 

Giotto  code  generation  for  FreeRTOS  creates  a  thread  for  each  distinct  frequency  specified 
in  a  Giotto  model.  In  addition  it  also  creates  a  scheduler  for  each  Giotto  director.  The  sched¬ 
uler  is  responsible  for  updating  the  ports  of  the  actors/tasks  specified  in  the  Giotto  models  as 
well  as  setting  the  initial  global  start  time.  Since  we  use  a  single  thread  to  set  the  global  start 
time,  we  avoid  the  non  determinism  that  would  be  possible  with  multiple  concepts  of  time  in  each 
thread.  Since  FreeRTOS  is  a  single-processor  fixed-priority  RTOS,  we  benefit  from  the  use  of 
the  vTaskDelayUntil  method  in  FreeRTOS  that  allows  a  method  to  “specify  the  exact  time  it 
wishes  to  unblock,  and  allows  cyclic  tasks  to  ensure  a  constant  execution  frequency.”  We  use  the 
vTaskDelayUntil  feature  in  each  scheduler  with  an  initial  common  start  time,  and  use  block¬ 
ing  semaphores  in  each  scheduler  as  well  as  in  task  threads.  The  top  most  Giotto  director  in  the 
model  is  given  it’s  own  scheduling  thread.  This  scheduling  thread  is  given  the  highest  priority  in 
the  system.  Schedulers  created  for  Giotto  Directors  in  lower  levels  of  the  hierarchy  are  given  a 
priority  equal  to  the  priority  of  the  actor  that  contains  the  Giotto  refinement,  threads  created  for 
tasks  with  high  frequencies  are  given  higher  priority  in  the  fixed  priority  scheme  than  tasks  with 
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lower  frequency  tasks. 


In  prior  work  llTSll.  E  machine  code  manages  the  deadline  and  releases  of  tasks.  We  accomplish 
the  same  mechanism  with  the  use  of  rate  monotonic  scheduling.  In  our  approach  we  create  a 
scheduler  for  each  Giotto  director  that  calls  driver  methods  at  a  specified  rate.  This  is  possible 
because  after  processing  the  driver  methods,  the  scheduler  yields  the  processor  to  the  next  available 
thread. 

In  some  methods  of  code  generated  for  a  Giotto  program,  the  S  machine  schedules  a  task  to 
be  completed  according  to  a  specified  frequency  using  either  rate  monotonic  or  earliest  deadline 
first  scheduling.  We  use  rate  monotonic  scheduling  by  assigning  threads  with  higher  frequency  a 
higher  priority  than  lower  frequency  threads.  After  completing  their  tasks,  each  frequency  thread 
yields  the  processor  until  it  is  told  by  the  scheduler  it  can  begin  execution. 

For  the  very  simple  Giotto  model  shown  in  Figure]^  we  generate  a  scheduling  thread  with  the 
highest  priority  in  the  system.  The  thread  created  to  handle  tasks  with  frequency  2  is  given  the 
second  highest  priority,  and  the  thread  to  handle  tasks  with  frequency  1  is  given  the  third  highest 
priority.  The  main  method  shown  in  Fisting]^ calls  the  initialize  method  shown  in  Fisting which 
initializes  the  necessary  variables,  and  creates  the  scheduling  and  frequency  threads.  The  main 
method  then  calls  the  vTaskStartScheduler()  method  required  to  start  threads  in  FreeRTOS.  When 
the  FreeRTOS  scheduler  starts,  it  begins  executing  the  thread  with  the  highest  priority,  in  this  case 
the  scheduling  thread.  In  the  scheduling  thread,  we  begin  executing  and  set  up  the  periodic  exe¬ 
cution  of  the  scheduler.  Fistings  Q  show  the  respective  variable  declarations;  frequency 
methods,  the  scheduler  method;  actor  methods;  and  driver  methods  generated  for  the  Giotto  model 
show  in  Figure]^ 


3.3  Scheduling 

In  our  design,  we  assume  each  actor  in  the  model  has  a  parameter  specifying  its  worst  case  exe¬ 
cution  time.  If  the  parameter  is  not  provided  a  default  value  is  used.  This  information  is  used  to 
determine  if  the  model  can  be  run  on  a  particular  platform  in  the  time  requested.  If  the  total  WCET 
for  all  actors  in  the  model  along  with  scheduling  overhead  is  unable  to  complete  in  the  desired 
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time,  the  Code  generation  adapter  warns  the  user  and  does  not  generate  the  eode.  If  the  sehedule  is 
feasible,  the  code  generation  adapter  generates  code  that  adheres  to  the  semantics  specified  in  the 
model.  To  determine  the  scheduling  feasibility  of  the  model  specified  we  use  Algorithms  and 
1^  Though  our  schedulabilty  analysis  determines  that  the  model  should  run  correctly  in  the  time 
specified,  we  also  use  semaphores  to  specify  when  it  is  safe  to  proceed  with  execution  in  case  there 
is  an  overrun.  If  a  task  overruns  we  have  the  scheduler  warn  the  user  of  the  overrun  and  block  until 
the  over  run  task  completes.  Our  warning  tells  the  user  that  because  of  the  overrun  task  they  will 
see  correct  ordering  of  execution  but  the  timing  constraints  may  be  violated.  We  plan  to  allow  the 
designer  to  specify  what  actions  should  be  taken  in  the  event  of  an  overrun  in  the  future,  instead  of 
simply  warning  the  user  and  blocking  progression  of  the  scheduler. 


Algorithm  1:  Scheduling  Algorithm 

Input:  A  =  {oi,  02,  03, ..,  an},  n  =total  actors  in  model 

Output:  Schedulability  of  model 

1.1  begin 

1.2 

wcetTotal< —  0; 

1.3 

foreach  a  e  A  do 

1.4 

wcetTotal  +  =  WCET(a); 

1.5 

end 

1.6 

wcetTotal  +  =  WCET(scheduler); 

1.7 

if  wcetTotal  <  Period  then 

1.8 

return  schedulable 

1.9 

else 

1.10 

return  not  schedulable 

1.11 

end 

1.12  end 

Since  Ptolemy  II  features  hierarchy  we  generate  schedulers  for  composite  actors  with  a  notion 
of  time.  Each  scheduler  for  a  composite  actor  uses  a  sub  clock  of  the  global  clock.  Since  the  sched¬ 
uler  for  a  composite  actor  also  needs  to  communicate  its  completion  to  the  top  most  scheduler,  we 
introduce  a  notion  of  an  iteration  of  time.  The  nested  scheduler  reports  that  one  iteration  of  itself 
has  occurred  after  it  has  seen  a  number  of  ticks  on  its  sub  clock  equivalent  to  the  least  common 
multiple  of  the  frequencies  seen  by  the  scheduler. 
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Algorithm  3:  Top  Most  Giotto  Scheduler  Algorithm 

3.1  b 

egii 

1 

3.2 

setGlobalClockO; 

3.3 

takeBeginPermissionFromThreadsO ; 

3.4 

schedTick  < —  0; 

3.5 

while  true  do 

3.6 

outputDrivers(schedTick) ; 

3.7 

inputDrivers(schedTick) ; 

3.8 

giveBeginPermissionToThreads(schedTick); 

3.9 

waitfornexttick; 

1.10 

schedTick  =  incrementAINReset(schedTick); 

/*  incrementAINReset ( . . )  increments  schedTick,  resets 

schedTick  to  0  if  schedTick  ==  LCM  */ 

1.11 

checkWarnBlock(schedTick) ; 

1.12 

end 

1.13  end 
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Algorithm  4:  Scheduler  Algorithm 

4.1  begin 

4.2 

waituntil  beginIterationMessage() ; 

4.3 

readGlobalClockO ; 

4.4 

takeBeginPermissionFromThreadsO ; 

4.5 

repeat 

4.6 

outputDrivers(schedTick) ; 

4.7 

inputDrivers(schedTick) ; 

4.8 

giveBeginPermissionToThreads(schedTick); 

4.9 

waitfornexttick; 

4.10 

schedTick  =  incrementAINEIteration(schedTick); 

/*  incrementAINEIteration ( . . )  increments  schedTick,  and 

says  endOf Iteration  ( )  if  schedTick  ==  LCM  */ 

4.11 

checkWarnBlock(schedTick) ; 

4.12 

until  endOfItemtionO  ; 

4.13 

sendEndIterationMessageO 

|.i4  end 
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3.4  Current  Design 


The  current  Giotto  C  code  generation  adapter  in  Ptolemy  II  is  able  to  generate  code  for  a  subset  of 
the  actors  in  Ptolemy  II;  in  addition,  the  adapter  framework  provides  support  for  the  Embedded- 
CActor.  The  EmbeddedCActor  allows  the  user  to  insert  C  code  for  any  unimplemented  actor  on 
their  target  and  incorporates  the  C  code  into  the  final  generated  file.  The  current  design  also  al¬ 
lows  the  Synchronous  Data  Elow(SDE)  model  of  computation  to  be  used  with  Giotto.  Each  Giotto 
director  in  a  model  is  expected  to  have  a  period,  and  each  actor  is  expected  to  have  a  frequency 
specified.  The  frequency  is  how  often  a  task  should  execute  within  a  period.  The  types  of  ports 
are  inferred  from  the  inputs  provided  or  from  the  type  the  actor  normally  accepts  or  outputs.  Also, 
task  code  from  each  actor  refers  to  its  input  and  output  variables.  To  transfer  data  from  an  output 
to  an  input  we  use  double  buffering  through  an  actor’s  output  variable  and  a  port  variable.  Drivers 
determine  when  values  are  copied  from  an  output  variable  to  a  port  and  from  port  to  an  input 
variable. 

The  scheduling  thread  is  given  the  highest  priority,  and  frequency  threads  are  assigned  a  priority 
lower  than  the  scheduling  thread.  Each  scheduler  is  called  at  the  rate  of  the  period  divided  by  the 
least  common  multiple  of  the  frequencies  in  the  mode.  Each  time  it  runs,  a  scheduler  checks  to 
see  if  a  previous  run  of  tasks  are  complete,  calls  the  driver  methods  of  the  actors  to  be  run  at 
that  particular  time,  sets  semaphores  indicating  which  frequency  threads  are  safe  to  execute,  and 
releases  the  processor  until  the  next  necessary  update.  The  scheduler  then  yields  the  processor  to 
the  task  threads  and  determines  whether  execution  of  the  task(s)  have  finished.  Currently,  we  block 
until  the  semaphore  is  available. 

The  higher  the  frequency  of  the  task,  the  higher  the  priority  of  the  frequency  thread  it  is  assigned 
to.  Each  frequency  thread  if  given  the  go  ahead  from  the  scheduler,  then  calls  the  methods  of  the 
tasks/actors  to  be  executed  at  that  frequency.  The  framework  handles  mode  switches  with  the 
modal  model  actor  in  Ptolemy  II.  The  modal  model  actor  is  a  finite  state  machine  actor  whose 
states  can  be  refined  to  contain  other  models.  In  this  framework,  the  inner  model  can  be  either 
SDE  or  Giotto. 

When  we  generate  code  for  a  composite  actor  without  a  director,  we  treat  the  composite  actor 
as  a  transparent  actor  and  generate  code  for  its  contents  directly.  When  we  generate  code  for  com- 
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posite  actors  with  a  director,  the  frequeneies  of  the  aetors  inside  the  eomposite  aetor  are  set  relative 
to  the  eomposite  aetor’s  frequeney.  When  we  set  the  frequeney  for  the  eomposite  aetor  seheduler,  it 
is  set  equal  to  the  period  of  the  top  -  direetor,  divided  by  the  least  eommon  multiple  of  the  frequen¬ 
eies  of  the  aetors  inside  the  eomposite  aetor,  divided  by  the  frequeney  of  the  eomposite  aetor.  If 
you  have  an  example  with  a  Giotto  direetor,  a  souree  (eonstant  output  1)  with  frequeney  1,  a  eom¬ 
posite  aetor  with  frequeney  2,  and  a  timed  plotter  with  frequeney  2.  The  eomposite  aetor  eontains 
a  Giotto  direetor,  and  an  aetor  with  frequeney  3.  The  frequeney  for  the  eomposite  aetor  sehed¬ 
uler  xFrequeney  is  {{{IQQQ /?>)  12) / PortTickRATEMS),  where  IQQQ/ PortTickRATEMS  is 
the  eonverted  period  (Is)  of  the  top  most  direetor  in  kernel  tieks,  3  is  the  least  eommon  multiple  of 
the  aetor  frequeneies  inside  the  eomposite  aetor,  and  2  is  the  frequeney  of  the  eomposite  aetor. 

Inside  the  seheduler  we  use  a  eounter  sehedTiek  whieh  determines  whieh  drivers  are  to  be 
exeeuted  on  this  run  of  the  seheduler.  The  sehedTiek  variable  is  initially  zero,  and  is  inere- 
mented  by  1  after  running  the  drivers.  The  sehedTiek  variable  is  reset  to  0  when  it  is  equal 
to  the  least  eommon  multiple  of  the  thread  frequeneies.  Drivers  are  run  if  {sehedTiek  mod 
(LCMofthreadfrequeneies/frequeneyoftask)  ==  0).  A  general  algorithm  for  eaeh  sehed¬ 
uler  is  shown  in  Algorithm]^ and 

Sinee  it  is  possible  for  the  WCET  speeified  to  be  too  small,  or  in  the  ease  where  there  is 
an  overrun  of  the  eode  being  exeeuted,  we  use  semaphores  to  determine  when  it  is  safe  to  begin 
exeeution  of  the  eode.  In  our  seheduler  we  use  a  warn  and  bloek  meehanism  that  displays  a  warning 
message  to  the  user,  and  then  bloeks  until  the  overrun  task  eompletes  its  exeeution. 


3.5  Drivers 

Drivers  are  ealled  by  the  seheduling  thread,  whieh  has  the  highest  priority  in  the  system.  The 
framework  eurrently  assumes  that  task  exeeution  is  shorter  than  the  LET  of  the  task.  If  a  task 
overruns  its  LET,  the  seheduling  thread  waits  until  the  eompletion  of  the  task  before  outputting  the 
value  to  the  port,  and  reading  a  value  from  the  port. 

In  this  implementation,  ports  are  written  to  at  the  beginning  of  a  driver’s  exeeution  and  values 
are  then  transferred  from  the  PORT  to  the  desired  inputs.  This  upholds  the  semantie  that  new 
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values  are  not  read  until  the  start  of  a  mode  period,  but  allows  aetuator  output  to  oeeur  as  elose  as 
possible  to  the  beginning  of  a  mode  period. 

3.6  Limitations 

If  WCET  parameters  are  not  provided  for  eaeh  aetor  we  eurrently  use  a  default  value  when  we 
ealeulate  WCET.  As  a  result,  though  our  sehedulability  eheek  may  tell  us  that  the  desired  sehedule 
is  feasible,  our  assumption  my  indeed  lead  to  overruns.  If  there  are  overruns  we  eurrently  warn 
the  user,  and  and  eontinue  exeeution  when  the  overrun  tasks  eompletes.  If  there  are  overruns, 
the  user  will  notiee  eorreet  ordering  of  exeeution  but  will  see  a  delay  in  outputs.  As  a  result  the 
eurrent  implementation  without  aeeurate  WCET  parameters  should  not  be  used  in  safety  eritieal 
applieations. 

One  should  also  note  that  there  is  a  limit  to  the  number  of  distinet  frequeneies  that  ean  be 
supported  sinee  the  thread’s  frequeney  determines  its  priority;  and  priorities  ean  only  be  assigned 
values  1  through  Seheduler  Priority- 1.  Seheduler  Priority  is  reserved  for  the  seheduler  of  the  top 
most  Giotto  direetor.  One  should  also  note  that  exeeuting  the  seheduling  thread  at  a  rate  relative 
to  the  least  common  multiple  of  frequencies  of  the  actors  in  the  model  since  execution  may  not  be 
necessary  on  every  run  of  the  scheduler.  One  alternative  to  this,  which  will  be  pursued  in  future 
work,  is  to  predetermine  which  ticks  of  the  scheduler  at  the  ECM  frequency  will  need  to  execute 
drivers  and  use  that  as  the  offset  interval  of  the  scheduler.  One  should  also  note  that  we  currently 
presume  that  each  EreeRTOS  thread  created  will  use  maximum  constant  amount  of  stack  space.  A 
more  efficient  use  of  memory  would  perform  an  analysis  of  the  content  of  the  C  code  generated 
for  each  actor  to  determine  the  maximum  stack  size  necessary. 

Eisting  1 :  Actor  and  Port  Variables 

1  /*  Simple -SimpleTaskE  '  s  input  variable  declarations  .  */ 

2  static  double  Simple. SimpleTaskE. input  [  1  ] ; 

3  /*  Simple  .SimpleTaskD  '  s  input  variable  declarations.  */ 

4  static  double  Simple.SimpleTaskD.input  [  1  ] ; 

5  /*  Simple -SimpleTaskA  's  referenced  parameter  declarations.  */ 

6  static  int  Simple. SimpleTaskA.step.  ; 

7  /*  Simple  .SimpleTaskA  ’s  type  convert  variable  declarations.  */ 

8  static  int  Simple.SimpleTaskA.output.O  ; 

9  static  int  Simple. SimpleTaskA. output  ; 

10  static  int  Simple. SimpleTaskA. output. PORT  ; 

11  /*  The  preinitialization  of  the  director .  */ 

12  /*  preinitSimpleTaskE  */ 

13  static  int  Simple. SimpleTaskE. . xvalue  ; 
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/*  preinitSimpleTaskD  */ 

static  int  Simple. SimpleTaskD._x value; 

/*  preinitSimpleTaskA  */ 
static  int  Simple_SimpleTaskA__state; 
unsigned  iong  g.ulSystemClock ; 
portTickType  gxLastWakeTime  ; 

# include  ”  semphr  .  h” 

xTaskHandle  Si mple .Giotto _Director__scheduler_task; 
xTaskHandle  Simple.Giotto.Director..frequencyl_task  ; 
xSemaphoreHandle  Simple_Giotto.Director._frequencyl  start; 
xSemaphoreHandle  Si  mple  _Giotto_Director__frequencyl  done; 
xTaskHandle  Simple. Giotto. Director. .frequency2_task  ; 
xSemaphoreHandle  S imple. Giotto. Director.. frequency 2start; 
xSemaphoreHandle  Simple _Giotto_Director__frequency2done; 


Listing  2:  Driver  Methods 


2  void  Simple. SimpleTaskE. driver. out  0  { 

3 

4  } 

5  void  Simple. SimpleTaskD. driver. out  0  { 

6 

7  } 

8  void  Simple. SimpleTaskA. driver. out  0  { 

Simple.SimpleTaskA.output.PORT  =  Simple. SimpleTaskA. output; 

Id  } 

11  void  Simple.SimpleTaskE.driver(){ 

12  Simple. SimpleTaskE. input  [0]  =  InttoDouble(  Simple.SimpleTaskA.output.PORT  ) ; 

d } 

void  Simple.SimpleTaskD.driver(){ 

Simple. SimpleTaskD. input  [0]  =  InttoDouble(  Simple.SimpleTaskA.output.PORT  ) ; 

if\ } 

void  Simple. SimpleTaskA. driver (){ 

} 


Listing  3:  Aetor  Methods 


\  Simple. SimpleTaskE  0  { 

PlotPointl  (  Simple  .SimpleTaskE  ..xvalue  ,  Simple.SimpleTaskE  .input  [0]); 
S  imple. SimpleTaskE..xvalue++; 


4  } 

5 

6  void 


Simple.SimpleTaskD  ()  { 

PlotPoint2  (Simple. SimpleTaskD. .xvalue  ,  Simple. SimpleTaskD. input  [0]); 
Simple. SimpleTaskD.. xvalue ++; 


1  Simple. SimpleTaskA  0  { 

Simple. SimpleTaskA. output  =  Simple. SimpleTaskA. .state; 

Simple. SimpleTaskA. .state  =  add.Int.Int(  Simple. SimpleTaskA. .state  , 


Simple.SimpleTaskA.step.); 


H } 


Listing  4:  Scheduler  Thread  Methods 

1  static  void  Simple  .Giotto. Direc  tor..scheduler  (  void  *  pvParameters){ 

2  portTickType  xLastWakeTime  ; 

3  int  schedTick  ; 

4  const  portTickType  xFrequency  =  ( ( ( 1  00/2 )/ 1 )/ portTICK.RATE.MS  ) ; 

5  char  warnl  =  0; 

6  char  warn2  =  0; 


xLastWakeTime  =  xTaskGetTickCount(); 


gxLastWakeTime  =  xLastWakeTime  ; 
schedTick  =  0; 

//  take  semaphores 

xSemaphoreTake (Simple_Giotto_Director__frequencylstart  ,(portTickType)0); 
xSemaphoreTake (Simple.Giotto_Director_. frequency 2start  ,(portTickType)0); 
xSemaphoreTake (  Simple. Giotto_Director_. frequency  1  done  ,(portTickType)0); 
xSemaphoreTake (Simple_Giotto_Director__frequency2done  ,(portTickType)0); 
for(;;){ 

if  (  schedTick  %2  ==  0){ 

Simple.SimpleTaskE.driver.outO; 

Simple.SimpleTaskA.driver.out  () ; 

} 

if(  schedTick  %1  ==  0){ 

Simple_SimpleTaskD_driver_out(); 

} 

if  (  schedTick  %2  ==  0){ 

Simple .SimpleTaskE.driver  (); 

Simple. SimpleTaskA. driver  (); 

xSemaphoreGive  (Simple.Giotto.Director..frequencyl  start); 

} 

if(  schedTick  %1  ==  0){ 

Simple. SimpleTaskD. driver  (); 

xSemaphoreGive  (Simple_Giotto_Director__frequency2start); 

} 

V  T  askDe  la  yUntil(& xLastWakeTime  ,xErequency); 
schedTick  ++; 
if(schedTick  ==  2)  { 
schedTick  =  0; 


if(  schedTick  %2  ==  0){ 

if  ( xSemaphoreTake  (Simple.Giotto.Director..frequencyldone  ,(portTickType)0) 


==  pdFALSE){ 


Warn( "  loverrun”); 


if(  schedTick  %1  ==  0){ 

if  ( xSemaphoreTake  (  Simple. Giotto. Director. .frequency2done  ,(portTickType)0) 


==  pdFALSE){ 


Warn ( "2 overrun  ”  ) ; 


if(  schedTick  %2  ==  0){ 
if(warnl  ==  1){ 

xSemaphoreTake  (Simple.Giotto.Director..frequencyldone  ,  portMAXJDELAY ) ; 


if(  schedTick  %1  ==  0){ 
if(warn2  ==  1){ 

xSemaphoreTake  (Simple. Giotto. Director.. frequency  2done  ,  portMAXJDELAY ) ; 


Listing  5:  Frequency  Thread  Methods 


static  void  Simple.Giotto.Director..frequencyl(void  *  pvParameters){ 
for(;;){ 

if  ( xSemaphoreTake  (Simple.Giotto.Director..frequencyl  start  , portMAXJDELAY)==  pdTRLfE){ 
Simple.SimpleTaskEO; 

Simple.SimpleTaskAO; 

xSemaphoreGive  (Simple.Giotto.Director..frequencyldone); 


static  void  Simple. Giotto. Director. .frequency2  (void  *  pvParameters){ 
for(;;){ 

if  ( xSemaphoreTake  (Simple. Giotto. Director.. frequency  2  start  ,  portMAXJDELAY)==  pdTRUE){ 
Simple. SimpleTaskD  () ; 

xSemaphoreGive  (Simple.Gi otto _Di rector  __frequency2done); 

} 

} 

} 
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Listing  6:  Initialize  Method 

void  i  n  i  t  i  a  1  i  ze  (  void  )  { 

/*  SimpleTaskA  's  parameter  initialization  */ 

Simple.SimpleTaskA.step.  =  1; 

#ifndef  .initlcd. 

#define  .initlcd. 

RIT128x96x4Init(  1000000); 

#endif 

xTaskCreate(  Simple. Giotto. Direct  or.. scheduler  ,  ’’Simple. Giotto. Director.. scheduler”  ,  100, 

NULL,  tskIDLE.PRIORITY  +  (unsigned  portCHAR)254  ,  Simple  .Giotto  .Direct  or.  .scheduler  .task  ' 
xTaskCreate(  Simple. Giotto. Director.. frequency  1  ,  ”  Simple. Giotto. Director.. frequency  1”,  100, 

NULL,  tskIDLE.PRIORITY  +  (unsigned  portCHAR)  1  ,  Simple. Giotto. Director. .frequency  I. task  ); 
vSemaphoreCreateBinary(Simple.Giotto.Director..frequencyl  start); 
vSem  aphoreCreateBinary  (Simple. Giotto. Director.. frequency  1  done); 

xTaskCreate(  Simple. Giotto. Director.. frequency 2  ,  ’’Simple. Giotto. Director. .frequency 2”  ,  100, 

NULL,  tskIDLE.PRIORITY  +  (unsigned  portCHAR)  2  ,  Simple. Giotto. Director.. frequency  2. task  ); 
vSemaphoreCreateBinary(  Simple. Giotto. Director.. frequency  2s  tart); 
vSemaphoreCreateBinary  (Simple. Giotto. Director.. frequency  2done); 

//initialize  actor  variables 
Simple. SimpleTaskA. output  =  0; 

/*  The  initialization  of  the  director .  */ 

/*  init  SimpleTaskE  */ 

Simple. SimpleTaskE..xvalue  =  0; 

{ 

int  mlc  ,  i  ; 
mlc  =  0; 

// RITl  28x96x4StringDraw  (  ”  Time  d  PlotterTe  St ’’ ,25  ,  0,  15); 

for(i  =  0;  i  <  128;  i+=  5) 

{ 

RIT128x96x4StringDraw(”_”  ,  i  ,89  ,5); 

} 

tor(i  =  0;  i  <  96;  i  +=8) 

{ 

RIT128x96x4StringDraw(”  |  ”  ,  0,i  ,5); 

} 

tor(i  =  0;  i  <  128;  i+=  5) 

{ 

RIT128x96x4StringDraw(”_”  ,  i  ,4  I  ,5); 

} 

} 

/*  initS  impleTaskD  */ 

Simple. SimpleTaskD. .xvalue  =  0; 

{ 

int  mlc  ,  i  ; 
mlc  =  0; 

//  RITl  28x96x4StringDraw  (  ”  Time  d  PlotterTe  st  "  ,25  ,  0,  15); 

for(i  =  0;  i  <  128;  i+=  5) 

{ 

RIT128x96x4StringDraw(”.”  ,  i  ,89  ,5); 

} 

for(i  =  0;  i  <  96;  i  +=8) 

{ 


RIT128x96x4StringDraw(”|’’,  0,i  ,5); 


i  ,41  ,5); 
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} 

for( i  =  0;  i  <  128;  i+=  5) 

{ 

RIT128x96x4StringDraw(”_”  , 

} 

} 

/*  initSimpleTaskA  */ 

Simple -Simplex  askA__state  =  convert  _Int_Int(0); 

} 


Listing  7 :  Main  Method 

1  int  main(int  argc  ,  char  *argv[])  { 

2  initializeO; 

3  g.ulSystemClock  =  SysCtlClockGet  ( ) ; 

4  vTaskStartSchedulerO; 

5  exit  (0); 

« } 


4  Case  Study  in  Elevator  Control 


As  a  demonstration  of  the  use  of  the  Giotto  C  Code  Generator  for  FreeRTOS,  we  speeify  a  model 
of  a  simple  elevator  eontroller  in  Ptolemy  II,  and  generate  eode  for  FreeRTOS  from  the  model. 
This  example  implements  a  variant  of  the  Toy  Elevator  problem  speeified  for  the  Spin  [jll  Model 
eheeker.  The  eontrols  are  for  a  very  simple  elevator  that  serviees  four  floors  of  a  building.  The 
elevator  is  initially  on  the  first  floor,  and  it  remains  on  the  last  floor  requested  by  the  user  with  its 
doors  open  awaiting  user  input.  This  example  demonstrates  only  a  subset  of  the  eapabilities  of 
the  code  generator  but  effectively  demonstrates  multi  modal  behavior,  even  without  refinements. 
Interaction  with  the  controller  was  done  via  a  web  page  shown  in  Figure  being  run  on  a  web 
server  running  on  the  Luminary  Cortex-M3. 

The  status  of  the  elevator  door  and  floor  are  shown  on  the  LCD  screen.  The  controller  details 
are  shown  in  Figures]^ and The  input  constants  for  pending  up,  down,  1, 2,3,4  are  tied  to  inputs 
from  the  web  interface  and  the  pending  status  variables  are  also  used  in  the  web  server.  It  is 
important  to  note  that  the  code  generation  process  creates  one  C  file.  Since  for  this  application 
the  controls  receive  information  from  the  web  server,  the  variables  for  the  input  constants  to  the 
controller  as  well  as  the  status  variables  are  moved  to  a  common  header  file,  seen  by  both  the  main 
file  and  the  web  server. 
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Figure  6:  Web  Interfaee  to  the  Elevator 
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Figure  7 :  Top  Level  of  Speoifieation 
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Figure  8:  States  in  ^  elevator  eontroller 


This  controller  is  simply  a  proof  of  concept,  in  fact  it  does  not  have  the  safety  precautions 
present  in  modem  day  elevators  such  as  a  bump  sensor.  It  has  an  alarm,  unlike  the  toy  elevator 
problem  specified  for  the  Spin  Model  checker,  where  the  elevator  stops,  and  outputs  a  sound  to 
indicate  the  alarm  has  gone  off.  One  should  note  that  if  the  alarm  button  is  pressed  it  preempts  all 
other  inputs. 

Please  note  that  we  do  not  have  WCET  analysis  available  for  the  CortexMS  and  that  we  are 
also  running  the  web  server  from  the  microprocessor.  Additionally,  we  handle  audio  in  the  Systick 
handler,  the  same  handler  used  by  FreeRTOS  to  handle  the  kernel.  As  a  result  we  see  correct 
ordering  of  outputs  however  as  is  to  be  expected,  audio  is  output  at  varying  speeds.  This  indicates 
the  we  would  not  be  able  to  successfully  play  music  if  we  attempted  to  use  the  code  generator 
without  WCET  analysis  tool  to  play  different  portions  of  a  song  that  need  to  be  pieced  together  at 
precise  times. 


5  Future  Work 


Current  work  indicates  the  potential  for  the  direct  use  of  a  real-time  operating  system  with  timed 
models  of  computation  if  the  RTOS  provides  a  mechanism  for  direct  control  over  timing.  We  plan 
to  extend  the  code  generation  framework  to  do  WCET  analysis  of  a  model  before  generating  code 
for  FreeRTOS  specifically  for  the  Euminary  board.  If  the  WCET  analysis  reveals  that  the  WCET  of 
tasks  is  longer  than  the  EFT,  we  plan  to  use  utility  functions  to  determine  what  should  occur  during 
an  overrun.  Options  include  stalling  until  the  task  completes,  resetting  the  processor  if  we  presume 
a  fatal  error  has  occurred  because  of  the  overrun,  or  continuing  execution  of  the  task  if  its  execution 
completes  within  a  certain  grace  time.  This  change  will  step  away  from  the  direct  mapping  between 
model  time  and  physical  time,  which  Giotto  generally  makes  equivalent,  and  allows  the  exploration 
of  delays  in  processing,  as  long  as  the  outputs  to  an  actuator  or  a  mode  port  are  delivered  in  time. 
This  approach  is  similar  to  the  approach  taken  in  PTIDES,  so  there  is  the  potential  for  concurrent 
development  of  both  projects.  In  addition  we  will  explore  mappings  of  Giotto  to  other  systems 
such  as  OSEK,  a  widely  used  RTOS  in  the  automotive  domain  as  well  as  pthreads,  as  long  as  they 
allow  some  control  over  timing  as  FreeRTOS  does.  We  will  also  demonstrate  that  the  Software 
Architecture  of  the  Ptolemy  II  code  generation  framework  is  modular  enough  to  allow  easy  re 
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targeting  to  another  RTOS. 
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